There are many existing ways of validating software or aiding in the development of low defect software. Early programs included assertions that halted a program when an unexpected condition occurred. A software developer would “assert” that a particular condition was true (e.g., that a variable held a certain value or a value within a known range) to ensure that the program state met the developer's expectations. This kind of checking is often in addition to any handling of errors that can occur during normal program operation, so that such checks might only be included in builds of the software program for testing. Later systems, such as exceptions, sought to allow programs to continue to run in the face of errors, and included semantics for ensuring proper cleanup of local variables (e.g., unwinding). These systems allowed the developer to write fast and straightforward software code for the normal case, and contain code for handling errors (e.g., exceptions) in a predefined area. Software developers sometimes call functions or include code that throws exceptions without handling those exceptions, leading to unhandled exception errors and sometimes program termination.
A more recent system of software development, known by the names design by contract, programming by contract, contract programming, behavioral interfaces, and contract-first development, describe an approach that includes formal, precise, and verifiable specifications for software components based upon the theory of abstract data types and the conceptual metaphor of a business contract. Contracts may specify preconditions, postconditions, object invariants, and so forth related to the operation of software. Contract preconditions impose a certain obligation for a client module to meet on entry to a particular component. Preconditions enable the component to avoid handling cases outside of the precondition. Contract postconditions guarantee a property on exit, such as that a variable will be in a specified range. Postconditions free the caller from handling cases outside of the postcondition. Object invariants ensure that software maintains a certain property upon entry and exit. Contracts provide information that can be used not only at runtime, but also by static analysis systems that verify software code by static inspection without running the code, and for other uses such as producing automatically checked documentation and enhancing Integrated Development Environment (IDE) support for programmers. For example, Microsoft Research described a design by contract system for use with Microsoft .NET at the 2008 Professional Developer's Conference (PDC).
Software has grown so complex that component reuse is common and many software programs invoke external components or include components (e.g., by static linking) internally that were not written or verified by the program author. For example, a data mining application may invoke a database library for establishing connections to a database and receiving data from the database in response to queries. In addition, programs may include whole platform paradigms that differ from the main paradigm of the program. For example, a native C++ application may invoke managed Microsoft .NET software classes to perform certain actions. Any part of such complex systems may include contracts as well as failures that other parts of the system do not anticipate or handle. For example, if a native application invokes managed code, and the managed code hits an exception or other failure, the native application state may be corrupted or the native application may terminate because the native application is unaware of or was not designed to handle the failure. Conversely, a managed application may call into native code that corrupts the application state or experiences some other failure.
A contract failure indicates that a program may be running in an unknown state, such as operating on parameter values or other data that the program author did not expect or expressly forbade. In many cases, contracts are enforced in debug builds through assertions and other facilities that provide information to the developer to find and handle a software defect. In retail builds, programs may not contain contract checks and may instead continue to run in spite of the unexpected condition, causing unexpected and possibly harmful behavior. In some cases, the unexpected condition may corrupt the state of the program and ultimately the user's data. Some systems may throw an exception when a contract fails, which the program may handle incorrectly or not handle at all, leading the operating system to shut down the program, or worse, the program incorrectly continues to run with corrupted data. This may not be desirable, particularly when the errant software program is running as part of a larger program that wants to continue running despite the failure. The handling of the contract failure may be incompatible with the way the rest of the program handles errors.